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Foreword 

This Technical Specification has been produced by the 3GPP. 

This TS defines the interfaces and Terminal Adaptation Functions (TAF) integral to a Mobile Termination (MT) which 
enables the attachment of asynchronous terminals to a MT within the 3GPP system. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an identifying 
change of release date and an increase in version number as follows: 

Version 3.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 Indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the specification; 
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Scope 



This Technical Specification (TS) defines the interfaces and Terminal Adaptation Functions (TAF) integral to a Mobile 
Termination (MT) which enables the attachment of asynchronous terminals to a MT (see GSM 04.02 [4]). The general 
aspects of Terminal Adaptation Functions are contained in GSM 07.01 [7]. This TS covers support of these services for 
the following interfaces and procedures: 

(i) V. 14 procedures 

(ii) V.21 DTE/DCE interface 

(iii) V.22bis DTE/DCE interface 

(iv) V.32 DTE/DCE procedures 

(v) 1.420 S interface 

(vi) V.25bis signalling procedures 

(vii) V.25ter signalling procedures 

The asynchronous data rates between the MT and the TE2 are defined in GSM 02.02 [2]. 

Note: From GSM R99 onwards the following services are no more required to be provided by a GSM PLMN: 

• the dual Bearer Services "alternate speech/data" and "speech followed by data" 

• the dedicated services for PAD and Packet access 

• BS21 ... 26andBS31 ...34 

The support of those services is still optional. The specification of these services is not within the scope of this TS. For 
that, the reader is referred to GSM Release 98. 



1.1 Normative references 

The following documents contain provisions, which through reference in this text, constitute provisions of the present 
document. 

References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

For a specific reference, subsequent revisions do not apply. 

For a non-specific reference, the latest version applies. 

A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[1] GSM 01.04: "Digital cellular telecommunication system (Phase 2+); Abbreviations and 

acronyms". 

[2] GSM 02.02: "Digital cellular telecommunication system (Phase 2+); Bearer Services (BS) 

supported by a GSM Pubhc Land Mobile Network (PLMN)". 

[3] GSM 03.10: "Digital cellular telecommunication system (Phase 2+); GSM Public Land Mobile 

Network (PLMN) connection types". 

[4] GSM 04.02: "Digital cellular telecommunication system (Phase 2+); GSM Public Land Mobile 

Network (PLMN) access reference configuration". 

[5] GSM 04.08: "Digital cellular telecommunication system (Phase 2+); Mobile radio interface layer 3 

specification". 

[6] GSM 04.21: "Digital cellular telecommunication system (Phase 2+); Rate adaption on the Mobile 

Station - Base Station System (MS - BSS) interface ". 

[7] GSM 07.01: "Digital cellular telecommunication system (Phase 2+); General on Terminal 

Adaptation Functions (TAF) for Mobile Stations (MS)". 
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[8] GSM 07.07: "Digital cellular telecommunication system (Phase 2+); AT command set for GSM 

Mobile Equipment (ME) 

[9] Reference not used. 

[10] CCITT Recommendation V.4: "General structure of signals of international alphabet No. 5 code for 

character oriented data transmission over public telephone networks". 

[11] CCITT Recommendation V.25 bis (1988): Blue book, Volume VIII, Fascicle VIII.l "Automatic 

Calling and/or Answering Equipment on the General Switched Telephone Network (GSTN) using 
the 100-Series Interchange Circuits". 

[12] ITU-T Recommendation V.25 ter: "Serial asynchronous automatic dialling and control". 

[13] CCITT Recommendation V.llO: "Support of data terminal equipments (DTEs) with V-Series 

interfaces by an integrated services digital network". 

[14] CCITT Recommendation V.24 (1988): Blue book. Volume VIII, Fascicle VIII.l "List of 

definitions for interchange circuits between data terminal equipment (DTE) and data 
circuit-terminating equipment". 

[15] CCITT Recommendation V.21 (1988): Blue book. Volume VIII, Fascicle VIII.l "300 bits per 

second duplex modem standardized for use in the general switched telephone network". 

[16] CCITT Recommendation V.14 (1988): Blue book. Volume VIII, Fascicle VIII.l "Transmission of 

start-stop characters over synchronous bearer channels". 

[17] CCITT Recommendation V.22bis (1988): Blue book. Volume VIII, Fascicle VIII.l "2400 bits per 

second duplex modem using the frequency division technique standardized for use on the general". 

[18] Reference not used. 

[19] CCITT Recommendation V.32 (1988): Blue book. Volume VIII, Fascicle VIII.l "A family of 

2-wire, duplex modems operating at data signalling rates of up to 9600 bit/s for use in the general 
switched telephone network and on leased telephone-type circuits". 

[20] CCITT Recommendation V.42 (1988): Blue book. Volume VIII, Fascicle VIII.l "error-correcting 

procedures for DCEs using asynchronous-to-synchronous conversion". 

[21] ITU-T Recommendation V.42 bis: "Data compression procedures for data circuit terminating 

equipment (DCE) using error correction procedures 

[22] CCITT Recommendation X.28: "DTE/DCE interface for a start-stop mode data terminal 

equipment accessing the packet assembly/disassembly facility (PAD) in a public data network 
situated in the same country". 

[23] Recommendations 1.3 10-1.470 (Study Group XVIII): Blue book. Volume III, Fascicle III.8, 

Overall network aspects and functions, ISDN user-network interfaces. 

[24] CCITT Recommendation 1.420: Blue book. Volume III, Fascicle III. 8 "Basic user-network 

interface". 

[25] Personal Computer Memory Card Association: "PCMCIA 2. 1 or PC-Card 3.0 electrical 

specification or later revisions". 

[26] Infrared Data Association IrDA "IrPHY Physical layer signalling standard". 

[27] TIA-617: "Data Transmission Systems and Equipment - In-Band DCE Control". 

[28] GSM 02.34: "Digital cellular telecommunications system (Phase 2+); High Speed Circuit 

Switched Data (HSCSD) - Stage 1" 

[29] GSM 03.34: "Digital cellular telecommunications system (Phase 2+); High Speed Circuit 

Switched Data (HSCSD) - Stage 2 Service Description" 
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[30] ISO 21 10: "Data communication — 25-pole DTE/DCE interface connector and contact number 

assignments" 

[31] GSM 09.07 (ETS 300 976): "Digital cellular telecommunication system (Phase 2+); General 

requirements on interworking between the Public Land Mobile Network (PLMN) and the 
Integrated Services Digital Network (ISDN) or Public Switched Telephone Network (PSTN)". 

[32] CCITT Recommendation V.25: "Automatic answering equipment and/or parallel automatic calling 

equipment on the general switched telephone network including procedures for disabling of echo 
control devices for both manually and automatically established calls". 

1 .3 Abbreviations 

Abbreviations used in this TS are Hsted in GSM 01.04 [1]. 



2 Reference Configuration 

GSM 07.01 [7] and GSM 04.02 [4] describe the basic reference configurations. 



2.1 Customer Access Configuration 



This configuration is as shown in figure 1 of GSM 04.02 [4]. This TS specifically refers to the Mobile Terminations 
(MTs) which support terminals of the type TBI and TE2 with asynchronous capabilities. The TAP is functionally a part 
of an MTl, MT2 or MTO with an integral asynchronous data capability. 

2.2 Terminal Adaptation Function (TAF) 

The TAF provides facilities to allow manual or automatic call control functions associated with circuit switched 
services. The following functions are also included: 

Conversion of electrical, mechanical, functional and procedural characteristics of the V series and ISDN type 
interfaces to those required by the PLMN. 

Bit rate adaptation of the V series data signalling rates and the ISDN 64 kbit/s to that provided in the PLMN. 

The mapping functions necessary to convert automatic calling and/or automatic answering procedures of 
recommendation V.25 bis or V.25 ter and parameters for asynchronous operation. 

The mapping functions necessary to convert S interface signalling to the PLMN Dm channel signalling. 

Flow control (in some cases resulting in non-transparency of data as described in subclause 4.3). 

Layer 2 Relaying (see annex A). 

In-call modification function. 

Synchronization procedure, which means the task of synchronizing the entry to and the exit from the data 
transfer phase between two user terminals. This is described in GSM 07.01 [7]. 

Filtering of channel control information as described in GSM 07.01 [7]. 

Terminal compatibility checking. 

Splitting and combining of the data flow in case of multiple substream data configurations. 
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3 Terminal Adaptation Functions for transparent 

services 

GSM 03.10 [3] refers to the connection types supporting the transparent services. 

3.1 Rate Adaptation 

GSM 04.21 [6] describes the rate adaptation scheme to be utilized over the Base Station (BS) to Mobile Station (MS) 
link. GSM 03.10 [3] refers to the rate adaptation elements to be provided in the MS. 

3.1 .1 Rate Adaptation - R interface 

This is provided as indicated in GSM 04.21 [6]. 

3.1 .2 Rate Adaptation - S Interface (1.420) 

The ISDN rate adapted frame format is modified to the PLMN rate adapted format as indicated in GSM 04.21 [6]. 

3.2 interciiange Circuit Signalling IVIapping - V-series interface 

The interchange circuit signalling at the interface between the TE2 and the MT shall conform to CCITT 
Recommendation V.24 [14]. The signals required at this interface are shown in table 3. 

The mapping of these signals to the pins of a 25 pin D-type connector is given in ISO 21 10. The mapping for a 
commonly used 9 pin connector is given in Annex B. 

3.2.1 Mapping of V.24 circuits to status bits 

Status bits SA, SB and X are used to convey channel control information associated with the data bits in the data 
transfer state. Table 1 shows the mapping scheme between the V.24 circuit numbers and the status bits for the 
transparent mode. It also shows how the unused status bits should be handled. It is derived from the general mapping 
scheme described in annex C. A binary corresponds to the ON condition, a binary 1 to the OFF condition. 

The transport of these status bits by the various channel codings is described in subsequent sections. 
Table 1 : Mapping scheme at the MT for the transparent mode 



Signal at TE2/MT 

interface or condition 

within the MT 


Mapping 
direction: MT to IWF 


Mapping 
direction: IWF to MT 


CT105 


not mapped (note 1) 




CT106 




from status bit X (note 7) 


CT107 




not mapped (note 5) 


CT108/2 


not mapped (note 6) 




CT109 




from status bit SB (note 7) 


CT133 


not mapped (note 2) 




always ON 


to status bit SA (note 3) 




always ON 


to status bit SB (note 1 ) 




always ON 


to status bit X (note 4) 




ignored by MT 




from status bit SA (note 3) 
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NOTE 1. The SB bit towards the IWF, according to the General Mapping (annex C), could be used to carry CT 
105. However, CT 105 should always be ON in the data transfer state since only duplex operation is 
supported. Also, many DTEs use the connector pin assigned to CT 105 for CT 133. No interchange 
circuit shall be mapped to the SB bit which shall always be set to ON in the data transfer state. 

NOTE 2. CT 133 is not mapped since there is no flow control in transparent mode. 

NOTE 3. The SA bits in both directions are available only with certain channel codings. Therefore, for maximum 
compatibility, they should not be mapped. 

NOTE 4. The X bit towards the IWF is not mapped and shall always be set to ON in the data transfer state since 
there is no flow control in transparent mode. 

NOTE 5. CT 107 is controlled by the channel synchronisation process (07.01). 

NOTE 6. CT 108/2 may be used in the call setup and answering processes. 

NOTE 7. The status bits are filtered before being mapped to the V.24 circuits (07.01). 

3.2.2 Single slot configurations (TCH/F9.6 or TCH/F4.8) 

GSM 04.21 [6] refers to the frame structure and identifies the use of the status bits for the carriage of signalling 
information in transparent mode. The S bits are put into two groups. SA is carried by bits S1,S3,S6,S8 and SB by bits 
S4,S9 in the ITU-T V.l 10 80-bit intermediate rate frame. 

3.2.3 Multislot configurations (TCH/F9.6 or TCH/F4.8) 

In transparent multislot configurations, status bits SI, S3 and the X-bit between the D12 and D13 - in the ITU-T V.llO 
80-bit intermediate rate frame - are used for transferring substream numbering information. The S4-bit is used for frame 
synchronization between the parallel substreams (reference GSM 04.21). The remaining S bits are put into two groups. 
SA is carried by bits S6,S8 and SB by bit S9. The remaining X bits can be used as described in section 3.2.1. 

3.2.4 Channel codings TCH/F14.4, TCH/F28.8 

For information on the mapping of the interchange circuit signalling bits in the 14,5 kbit/s multiframe structure, refer to 
GSM 04.21. There is no SA bit in this channel coding. Only the SB and X bits are carried. 

3.3 Interface Signal Levels - R interface 

The signal levels at the interface between the TE2 and the MT shall conform to CCITT V.28, or to IrDA IrPHY 
physical signalling standard specification, or to PCMCIA 2.1, or to PC-Card 3.0 electrical specification or to later 
revisions. 

3.4 Call Establishment and Clearing Signalling IVIapping 
3.4.1 V-series interface Autocalling/answering 

The mapping of the V.25 bis [11] procedures to the messages of the PLMN signalling in GSM 04.08 [5] is defined in 
section 5. 

a) Auto Calling 

This procedure is provided according to V.25 bis [11] using only 108/2. 

A subset of V.25 bis is shown in table 3. This subset gives minimum level of control and indication. 

During the call establishment phase, i.e. after signalling, calling tone according to V.25 [32] shall be generated in 
the IWF (GSM 09.07 [31]). 
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An alternative to CCITT V.25bis [1 1] is to use the ITU-T V.25 ter [12] dial command as specified in 
GSM 07.07 [8]. 

b) Auto Answer 

This procedure is provided according to V.25bis [11] or to V.25 ter [12]. 

During the call establishment phase: 

- the states of the V.24 interchange circuits shall be according to GSM 07.01 [7], 

- the data and status bits from the IWF shall not be mapped, 

- the data and status bits towards the IWF shall be according to GSM 07.01[7]. 

3.4.2 S Interface (1.420) Signalling Mapping 

The mapping of Q. 931 signalling to GSM 04.08 [5] signalling requires the inclusion, by the MT, of PLMN specific 
elements (e.g. transparent or not, half/full rate channel). For asynchronous Bearer services, requests for bearer 
capabilities not listed in table 4 (or where the "Users information layer 1 protocol" element does not indicate V.l 10) 
will result in call rejection. 

3.4.3 Call Establishment Manual Operation - Utilizing the Unrestricted 
Digital Capability 

In this case the user will not hear network supervisory tones or answer tone. The data transfer phase will be entered 
automatically. 

3.4.4 V-series interface Call Clearing 

This procedure is provided according to V.25 bis [11] using CT 108/2. An alternative to CCITT V.25bis [11] is to use 
the V.25 ter [12] hook control command or the hangup commands specified in GSM 07.07 [8]. The mapping of the 
V.25 bis [11] procedures to the messages of the PLMN signalling in GSM 04.08 [5] is defined in section 5. 



During the call clearing phase: 

- the states of the V.24 interchange circuits shall be according to CCITT V.24 [14], 

- the data and status bits from the IWF shall not be mapped or used by the MT in any way, 

- the data and status bits towards the IWF have no significance and may be set to 1 and OFF respectively. 

4 Terminal Adaptation Functions for non-transparent 

services 

GSM 03.10 [3] refers to the connection types supporting the non-transparent services. 

4.1 Data Structure 

4.1 .1 Data Structure on S Interface 

The protocol models for this are described in cases 3a and 3d of GSM 03.10. The data structure will be according to 
CCITT V.l 10. 
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4.1 .2 Data Structure on R Interface 

The protocol models for this are described in cases 3b and 3e of GSM 03.10. The data will consist of 7 or 8 bit 
characters with additional start and stop elements. The 7 bit data can additionally have an associated parity bit, 8 bit 
data cannot have an additional parity bit. 

The interchange circuit signalling at the interface between the TE2 and the MT shall conform to CCITT 
Recommendation V.24 [14]. The signals required at this interface are shown in table 3. 

The interface shall provide inband (XON/XOFF) and out of band (CT106) flow control. The use of CT133 for out of 
band flow control shall be implemented according to CCITT Recommendation V.42 [20]. 

4.1 .3 Data Structure Provided by the L2R Function to tine RLP Function 

See annex A. 



4.2 



Signalling Mapping 



4.2.1 Interchange Circuit Signalling Mapping - V-series interface 

Status bits SA, SB and X are used to convey channel control information associated with the data bits in the data 
transfer state. Table 2 shows the mapping scheme between the V.24 circuit numbers and the status bits for the non- 
transparent mode. It also shows how the unused status bits should be handled. It is derived from the general mapping 
scheme described in annex C. A binary corresponds to the ON condition, a binary 1 to the OFF condition. 

The transport of the status bits by the L2RCOP is described in annex A. 

Table 2: Mapping scheme at the MT for the non-transparent mode 



Signal at TE2/MT 

interface or condition 

within the MT 


Mapping 
direction: MT to IWF 


Mapping 
direction: IWF to MT 


CT105 


not mapped (note 1) 




CT106(note4) 




from status bit X (note 7) 


CT107 




not mapped (note 5) 


CT108/2 


not mapped (note 6) 




CT109 




from status bit SB 


CT 133 (note 8) 


to status bit X (notes 3,8) 




always ON 


to status bit SA (note 2) 




always ON 


to status bit SB (note 1 ) 




ignored by MT 




from status bit SA (note 2) 



NOTE 1. The SB bit towards the IWF, according to the General Mapping (annex C), could be used to carry CT 
105. However, CT 105 should always be ON in the data transfer state since only duplex operation is 
supported. Also, many DTEs use the connector pin assigned to CT 105 for CT 133. No interchange 
circuit shall be mapped to the SB bit which shall always be set to ON in the data transfer state. 

NOTE 2. The SA bits (both directions) are not mapped since CTs 107 and 108/2 are handled locally (notes 5, 6). 

NOTE 3. The condition of status bit X towards the IWF may also be affected by the state of the receive buffer in 
the MT. 

NOTE 4. The state of CT 106 (or other local flow control mechanism) may also be affected by the state of the 
transmit buffer in the MT and the state of the RLP (RR/RNR). 
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NOTE 5. CT 107 is controlled by the channel synchronisation process (07.01). 

NOTE 6. CT 108/2 may be used in the call setup and answering processes. 

NOTE 7. For inband local flow control, changes in the condition of the status bit X from the IWF also result in the 
sending of XON or XOFF to the DTE. 

NOTE 8. For inband local flow control, CT 133 is not mapped and the status bit X towards the IWF is controlled 
by the reception of XON and XOFF characters from the DTE. 

4.2.2 Call Establishment and Clearing Signalling Mapping 

This is identical to the transparent case with the exception of the transparent/non-transparent element, see section 5. 

In addition, the L2R/RLP will give an explicit indication when the link into the connected network is established. If the 
link fails, an explicit "link lost" indication will be given. 

4.3 Flow Control 

The passage of flow control information between L2Rs is described in annex A. Subclauses 4.3.1, 4.3.2 and 4.3.3 
describe the operation of the flow control mechanisms. These mechanisms apply for all the non-transparent services 
covered by this specification, with the exception of Character Orientated Protocol with No Flow Control which is 
treated in subclause 4.3.4. 

4.3.1 Conditions Requiring Flow Control towards the Network 

The L2R function will send immediately a "flow control active" indication in the following circumstances: 

(i) If the receive buffer from the radio side reaches a preset threshold (BACKPRESSURE). 

(ii) If local flow control is initiated by the TE2 (see subclause 4.3.3 a) or c)). On receipt of this flow control 
indication transmission of data from the receive buffer towards the TE2 is halted. 

On removal of the buffer congestion or local flow control the L2R will send a "flow control inactive" indication. 

In addition, for the local flow control condition, transmission of data from the receive buffers will be restarted. 

4.3.2 Conditions Requiring Flow Control towards TE2 

The L2R functions will immediately activate local flow control (see subclause 4.3.3 b) or d)) under the following 
circumstances: 

(i) The transmit buffer reaches a pre-set threshold (BACKPRESSURE). 

(ii) The L2R receives a "flow control active" indication. 

On removal of buffer congestion or receipt of L2R/RLP "flow control inactive" the local flow control will be removed. 

4.3.3 Local Flow Control 

Two methods of local flow control are allowed: 
Outband 

a) From TE2: CT133 shall be turned OFF to indicate flow control active, and ON to indicate flow control inactive. 

b) From TAF: CT106 shall be turned OFF to indicate flow control active, and ON to indicate flow control inactive. 
Inband 
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c) From TE2: XOFF (DC3) is sent to indicate flow control active. XON (DCl) is sent to indicate flow control 
inactive. The XON/XOFF characters received from the TE2 are extracted by the L2R from the data stream and 
are not sent across the radio interface. Where XON/XOFF is utilized then the TAF will generate flow control 
active/inactive immediately, i.e. the XON/XOFF characters do not enter the transmit buffer. 

d) From TAF: As from TE2 

If the outband method is used, the L2R will pass the DC1/DC3 characters as data, i.e. no flow control indications will 
be generated on receipt of DC1/DC3. 

4.3.4 Character Orientated Protocol with No Flow Control 

If the users layer 2 indicates Character Orientated Protocol with no flow control then no flow control is used, i.e. the 
X-bit is not set to OFF and DC1/DC3 characters are passed through as data. 

4.4 Buffers 

4.4.1 TX Buffers 

Data received on CT103 from the TE2 shall be buffered such that if the MT is unable to transfer the data over the radio 
path then data is not lost. 

The buffer shall be capable of holding the data. Its size is up to the implementers. 

When the buffer is half full, TE2 shall be flow controlled as per subclause 4.3.2, unless Character Orientated Protocol 
with No Flow Controlis being used (see subclause 4.3.4). 

4.4.2 RX Buffers 

Data for transfer to the TE2 on CT104 shall be buffered such that if the TE2 is unable to accept data then data 
transferred from the MT is not lost. 

The buffer size should be up to the implementers. 

When the buffer becomes half full, the L2R will send a "flow control active" indication, unless Character Orientated 
Protocol with No Flow Control is being used. 

4.5 Bit Transparency 

V.25bis indications generated by the TAF shall be even parity, even if the parity condition for the user's application is 
different. 

4.6 Transportation of "BREAK" condition 

The "BREAK" condition must be recognized by the L2R function and passed immediately to the IWF. The L2R will 
generate a "BREAK" condition to the TE2 on receipt of a "BREAK" indication from the IWF. 

Annex A describes how the L2R will transport the "BREAK" indication. 



4.7 Data Compression 



L2R optionally includes a data compression function according to ITU-T V.42bis that spans from the MS to the IWF in 
the MSC. The error correction function is provided by RLP instead of ITU-T V.42. RLP XID is used to negotiate 
compression parameters. L2R includes the V.42bis control function especially for reinitializing in case of break 
recognition or RLP reset and error indication by the data compression function respectively. 
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Table 3: Minimum set of Interchange Circuits 



Circuit 
Number 


Circuit 
Name 


Ground 


Data 


Control 


To 


From 


To 


From 








TE2 


TE2 


TE2 


TE2 


CT102 


Common 
return 


X 










CT103 


Trans- 
mitted 
data 






X 






CT104 


Received 
data 
return 




X 








CT105 


Request 
to send 
(Note 2) 










X 


CT106 


Ready 

for 
sending 








X 




CT107 


Data set 
ready 








X 




CT108/2 


Data 

terminal 

ready 










X 


CT109 


Data 

channel 

received 

line 

signal 

detector 








X 




CT125 


Calling 
indicator 
(Note 1) 








X 




CT133 


Ready for 

Receiving 

(Note 2) 










X 



NOTE 1: CT125 is used with the automatic answering function of the TAP. 

NOTE 2: CT105 and CT133 are assigned to the same connector pin on both the standard 25 pin connector (ISO 
21 10) and the commonly used 9 pin connector (annex B). When this pin is used for CT133 then on the 
DCE (MT) side of the interface CT 105 is treated as being always in the ON condition. Similarly, when 
this pin is being used for CT105 then on the DCE (MT) side of the interface CT 133 is treated as being 
always in the ON condition. As circuit 133 is used only in duplex operation and circuit 105 is used only 
in half duplex operation (which is not supported by GSM) there should be no conflict. 



£75/ 



(3G TS 27.002 version 3.2.0 Release 1999) 



16 



ETSI TS 127 002 V3.2.0 (2000-01) 



Table 4: Minimum Set of Call Set-up Commands and Indications 





Description 


IA5 Characters 


Commands 
from TE2 


Call Request with Number 
provided 0,1. .9,*,#,A,B,C,D 

Connect incoming Call 

Disregard Incoming Call 


CRN 

CIC 
Die 


Indications 
toTE2 


Call Failure Indication 
XX = CB,AB,NT,FC(Note) 

INcoming Call 

VALId 

INValid 


CFIXX 

INC 
VAL 
INV 



NOTE: CB = Local MT busy 
AB = Abort call 
NT = No answer 
FC = Forbidden call * 

* Forbidden call indication results from contravention of rules for repeat call attempts as defined by the 

appropriate national approvals administration. It is recommended that this is the responsibility of the MT, 
not the TE2. 



5 Terminal interfacing to GSIVI 04.08 IVIapping 

Only those elements/messages that are of particular relevance are considered. 

Interface procedures not directly mappable to GSM 04.08 [5] (i.e. V.25 bis VAL/INV) are not considered. Mobile 
management procedures of GSM 04.08 [5] are not considered applicable. 

Mapping of other call establishment or clearing messages to the S interface e.g. "Call proceeding" etc. have not been 
included. It is assumed these will be able to be mapped directly and are of no relevance to the V.25 bis or manual 
interface. 

For the Alternate speech/group 3 facsimile service it will be necessary for the TAP to generate a "Modify" message for 
transmission on the Dm channel. This shall be according to the defined procedure in GSM 04.08 [5]. 
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5.1 Mobile Originated Calls 

Call establishment is initiated by the keypad or DTE action: 
a) Setup 



Element 


Derived from 


MMI 


V.25 bis message 


S interface message 


Called 
Address 


Keypad 


CRN/CRI/CRS 


Setup 


Called 
Sub Address 

HLC 


Keypad 


CRI 


Setup 
Setup 


Derived from internal 
settings or MMI infor- mation. 


LLC 


Same as HLC 


Setup 


BC 


Same as HLC GSM 07.01 

gives 

allowed values 


Setup (witfi addi- 
tional information 
from MMI originated 
settings) 



b) Release Complete 



Element 


Derived from 


MMI 


V.25 bis message 


S interface message 


Cause 


Display 
(optional) 


CFI 


Release Complete 



5.2 IVIobile Terminated Calls 

Call establishment is initiated by receipt of Setup at the MS: 
a) Setup 



Element 


Mapped on to 


MMI 


V.25 bis message 


S interface 








message 


Called 


Display 


INC 


Setup 


Address 


(optional) 






Called Sub 


Display 


Not applicable 


Setup 


Address 


(optional) 






HLC 


Display 
(optional) 


Not applicable 


Setup 


LLC 


Display 
(optional) 


Not applicable 


Setup 


BC 


Display 


Not applicable 


Setup (with PLMN 




(optional) 




specific elements 
removed) 



b) Call Confirm 

Information for the BC element in the call confirm is derived from e.g. MMI or by internal settings. 

c) Connect 
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Connect is sent in response to connect from the S interface, from MMI, or when the timeout period referred to in 
V.25bis has expired. This period shall be between 5 and 10 seconds. During this time the automatic answering of the 
incoming call can be prevented by issuing a DIC command. The CIC can be used to cancel the effect of a preceding 
Die command (see Recommendation V.25bis [11]). 

5.3 Call Clearing 
5.3.1 Mobile initiated 

Call clearing is initiated by the keypad or DTE action: 
Disconnect 



Element 


Derived from 


MMI 


V.25 bis 


S interface message 


Cause 


Keypad 


DTE shall turn CT 108/2 
OFF 


Disconnect 
or inband V. 110 disconnect request 



5.3.2 Network initiated 

Call clearing is initiated by receipt of Disconnect at the MS: 
Disconnect 



Element 


Mapped on to 


MMI 


V.25 bis 


S interface message 


Cause 


Display 
(optional) 


MS shall turn CT 107 
OFF 


Disconnect 
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Annex A (Normative): 
L2R Functionality 

A.1 Introduction 

This annex describes the L2R functionality for non-transparent character oriented protocols. The general aspects of 
L2Rs are described in GSM 07.01 [7]. Figure 1 shows the 3 sub-functions of a character oriented L2R. 



CONTP 




L2RC0P 



CONTP Character Oriented Non-Transparent Protocol 

CORE Character Oriented Relay Entity 

L2RCOP L2R Character Oriented Protocol 

Figure 1 
Section 2 describes the L2R Character Oriented Protocol (L2RCOP) and section 3 the use of the L2RCOP. 



A.2 The L2RC0P 



Information is transferred between L2Rs in fixed length n octet Protocol Data Units (PDUs). This corresponds to the 
fixed length of the RLP frame information field. The octets within the L2RCOP-PDU are numbered to n-1, octet is 
transmitted first. The value of n depends on the negotiated RLP version and frame type (GSM 04.22). The bits within 
the octets are numbered 1 to 8, bit 1 is transmitted first. 

The RLP version value 2 indicates RLP multi-link operation. The RLP version value or 1 indicates RLP single-link 
operation. 

Each octet contains a status octet, an information octet or fill 

Octet contains either a status octet or a user information octet. 

Octet shall always contain a status octet in case at least one status octet is transported in the L2RCOP PDU. In 
RLP-versions and 1 a PDU always carries at least one status octet. In RLP version 2 a PDU carries status 
octet(s) only if actual status change(s) has taken place within the period represented by the PDU. Here the L2R 
status flag in the RLP version 2 header is set to 1 when status octet(s) is carried in the PDU. 

Status octets contain 3 status bits and 5 address bits. In cases where two status octets within the PDU are 
separated by more than 23 octets, the first status octet in octet m is followed by a pointer octet in octet m-nl 
forming a two-octet status field. The pointer octet contains one reserved bit and seven address bits indicating the 
number of characters between the status field and the second status octet. 
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The 3 status bits correspond to SA, SB and X in CCITT Recommendation V.l 10. The SA, SB and X bits use bit 
positions 8,7,6 in the status octets. When a status bit changes the current state of all three bits shall be 
transmitted. 

Information octets are character octets or encoded character octets 

Character octets are coded in the following way: 

The first bit of the character received/transmitted corresponds to bit position 1 in the octet. The second bit to 

bit 2, and the seventh bit to bit 7. For order of transmission of 1A5 characters see CCITT 

Recommendation V.4 [10]. 

7 bit characters are padded with a in bit position 8. Received parity (if used) is inserted in bit position 8, if 
parity is not used bit 8 is set to 0. 

Any start/stop bits are removed by the L2R. 

Encoded character octets are provided by the compression function. They are encoded according to ITU-T 
V.42bis. 

Information octets are inserted into L2RCOP-PDUs in order of transmission in octets 1 to n-1 for RLP single- 
link operation, in octets 1 to n-1 for RLP multi-link operation with status octet transportation, and in octets to 
n- 1 for multi-link operation with no status octet transportation. 

The address field in the status octets indicates the position of next status octet within the L2RCOP-PDU. This 
indicates the number of characters between status octets. Thus if two status octets are inserted into 
L2RC0P-PDU at offsets 1 and m the address value will be defined by m-1-1. Address bit 2° corresponds to bit 1 
in the status octets. Address bit 2' to bit 2 etc. 

Status octets are inserted in the character stream whenever a status change needs to be transmitted. 

Only address values 1 to n-2 (n-2 < 23) in the address field of status octets are used for addressing purposes. The 
implication of not allowing address value to be used for addressing is that two status octets cannot be sent after 
each other. The remaining codes are used to indicate: 

Last status change, remainder of L2RCOP-PDU empty. Address field value 3 1 

Last status change, remainder of L2RCOP-PDU full of characters. Address field value 30 

Destructive break signal, remainder of L2RCOP-PDU empty. Address field value 29 

Destructive break acknowledge, remainder of L2RCOP-PDU empty. Address field value 28 

L2RCOP-PDU contains at least two status octets which are separated by more than 23 characters; the 
address-field value in the first octet of the two-octet status field is 27 and the address bits in the pointer 
octet of the status field indicate the number of characters between the two-octet status field and the next 
status octet. 

Address field values from n-1 to 26 are reserved. In case of a PDU more than 25 octets in length, address 
field values from 24 to 26 are reserved. 

When it is necessary to insert a status octet into the character stream when no status change has occurred, e.g. to 
indicate that the reminder of a L2RCOP-PDU is empty or to indicate a break signal, the current status shall be 
repeated. 

In case when 64 data octets are carried by a 66-octet PDU, a status octet is carried in octet and another status 
octet within the first 24 data octets. (The first status octet gives the address of the second status octet, which 
carries value 30 in its address field.) 

Three examples of an L2RCOP PDU are shown in Figure 2. 
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n-1 



8 


7 


6 


5 


4 


3 


2 1 


SA 


SB 


X 











1 1 


1 


1 











1 


1 1 


1 


1 





1 








1 1 


1 


1 








1 


1 


1 


SA 


SB 


X 


1 


1 


1 


1 1 







IA5 "G" (odd parity) 
IA5 "S" (odd parity) 
IA5 "M" (odd parity) 
(last status cliange, rest of PDU empty) 



Figure 2a Single-link RLP and multi-link RLP with status octet transfer in PDU. 



8 


7 


6 


5 


4 


3 


2 1 


1 


1 





1 








1 1 


1 


1 











1 


1 1 


1 


1 





1 








1 1 


1 


1 








1 


1 


1 






1 


1 








1 


1 


1 



IA5 "S" (odd parity) 
IA5 "G" (odd parity) 
IA5 "S" (odd parity) 
IA5 "M" (odd parity) 



n-1 1 10 110 1 IA5 "M" (odd parity) 

Figure 2b Multi-link RLP L2RC0P PDU with no status octet transfer 

8 7 6 5 4 3 2 1 



41 
42 
43 



65 



SA 


SB 


X 











1 


1 


1 


1 








1 


1 





1 


1 


1 

















1 


1 


1 





1 








1 





SA 


SB 


X 


1 


1 





1 


1 


R 





1 











1 


1 




SA 


SB 


X 














1 


1 


1 








1 


1 





1 


SA 


SB 


X 


1 


1 


1 


1 







1 


1 








1 


1 


1 


1 



IA5 "IVI" (odd parity) 
IA5 "A" (odd parity) 
IA5 "R" (odd parity) 



IA5 "K" (odd parity) 



IA5 "O" (odd parity) 



Figure 2c A 66-octet RLP L2RC0P PDU with status octets separated by more than 23 octets 
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A.3 Use of the L2RC0P 

The CORE relays status changes, break conditions and characters in both directions between the CONTP entity and the 
L2RC0P entity. 

The L2RCOP entity performs the following functions. 

A.3.1 Radio Link Connection Control 

Given appropriate indications from the signalling mechanisms the L2RCOP entity uses the services of the radio link to 
establish and release the connection to its peer L2RC0P entity in the IWF. 

A.3.2 Data Transfer 

The L2RCOP entity will assemble and disassemble L2RC0P-PDUs. Data characters are assembled into 
L2RCOP-PDUS until either: 

- The PDU is full 

The Radio Link service can accept another Radio Link service Data Unit. 

L2RC0P-PDUs are transferred to the peer L2RCOP entity using the data transfer services of the radio link. 

A.3.3 Status Transfer 

The L2RC0P entity transfers interface status information between L2Rs using bits SA, SB and X in the status octets in 
L2RC0P-PDUS. Status changes are inserted in the L2RC0P-PDU in the position corresponding to the position in the 
character stream that the interface status change occurred. When the RLP is established or reset a L2RCOP-PDU with 
the current status values shall be sent. 

The general mapping between V.24 interface circuit numbers and status bits is described in annex C. A binary 
corresponds to the ON condition, a binary 1 to the OFF condition. The specific mapping at the MT for the non- 
transparent bearer service is given in section 4.2. L The mapping schemes used at the IWF are given in GSM 09.07 [31]. 

A.3.4 Flow Control 

Flow control information is transferred between L2Rs in 2 ways, these are: 
back pressure caused by L2R buffer conditions 
use of the X-bit in status octets: 

flow control active, X-bit = ONE 
flow control inactive, X-bit = ZERO 

A.3. 5 Break 

The transfer of break conditions between L2Rs is via the status octets with appropriate coding of the address field. 
Where the "Break Signal" is generated it shall conform to the definition shown in CCITT Recommendation X.28. 

A.3. 5.1 Normal Realization 

The L2RCOP-PDU contains the mandatory status octet coded as the Destructive Break. 

Upon the receipt of the "Break Signal", the L2R will destroy any existing data in front of the Break Signal in the same 
direction, and all the buffered data in the other direction. The L2R will then pass the Break Signal immediately on. 
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The termination of a break condition is indicated by sending an L2RCOP-PDU containing characters. 

A.3.5.2 Realization in case of Data Compression is used 

If the data compression function is used L2RCOP has to ensure the synchronization of the encoder and decoder 
according to ITU-T V.42bis. 

Upon receipt of a L2RC0P-PDU containing a status octet that signals a Destructive Break L2R destroys all data in the 
TX and RX buffer and re-initializes the compression function. Then L2R will transmit a L2RCOP-PDU that contains 
the mandatory status octet coded as the Destructive Break Acknowledge. After that L2R will restart the data transfer. 

Upon an receipt of the "Break Signal" by the CONTP, the L2R destroys any existing data in the TX and RX buffer and 
will then pass the Break Signal immediately by using L2RCOP-PDU containing a status octet coded as the Destructive 
Break. L2R will wait for a L2RCOP-PDU containing a mandatory status octet coded as Destructive Break 
Acknowledge. Following data received by the CONTP will be stored in the TX buffer. Data received in L2RCOP-PDUs 
will be discarded. After reception of the L2RCOP-PDU containing a mandatory status octet coded as Destructive Break 
Acknowledge L2R will re-initialize the data compression function and restart the data transfer. 
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Annex B (Informative): Use of a 9 pin connector as an l\/IT2 
type interface 

For asynchronous data communications many of the physical pins on a standard 25 pin D-type connector (ISO 21 10) 
are not used. As a result many communication devices have only a 9 pin connector to allow them to be made smaller. 
This interface is a MT2 type providing the correctV.24 signals are supported. 

Table B 1 gives the pin assignments for a 9 pin connector. Two variants are permitted - 

1. Outband flow control 

When outband (CT 133) flow control is required, pin number 7 carries CT 133 (Ready for Receiving). In this case CT 
105 is not mapped to any physical pin. On the MT2 side of the interface, CT 105 is treated as being always in the ON 
condition. 

2. No outband flow control 

When no outband (CT 133) flow control is required, pin number 7 may carry CT 105 (Request to Send). In this case CT 
133 is not mapped to any physical pin. On the MT2 side of the interface, CT 133 is treated as being always in the ON 
condition. 

Table B1 : Interchange circuit mappings 



V.24 Circuit Number 


Circuit Name 


Pin Number 


CT102 


Common ground 


5 


CT103 


TxD 


3 


CT104 


RxD 


2 


CT105 


RTS 


7 (note) 


CT106 


RFS (CIS) 


8 


CT107 


DSR 


6 


CT 1 08/2 


DTR 


4 


CT109 


DCD 


1 


CT125 


CI 


9 


CT133 


RFR 


7 (note) 



NOTE: Only one of these mappings may exist at any one time. 
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Annex C (informative): 
General mapping of V.24 circuits to channel status bits 

In the data transfer state, status bits SA, SB and X can be used to convey channel control information associated with 
the data bits. Table CI shows the general mapping scheme between the V.24 circuit numbers and the status bits. A 
binary corresponds to the ON condition, a binary 1 to the OFF condition. The specific mappings for the various GSM 
bearer types are given elsewhere in this specification. 



Table CI : General mapping scheme at the MT 



Signal at TE2/MT 
interface 


Status bit 
direction: MT to IWF 


Status bit 
direction: IWF to IVIT 


CT105(note3) 


SB 




CT106(note1) 




X 


CT107 




SA 


CT108/2 


SA 




CT109 




SB 


CT 133 (note 3) 


X (note 2) 





NOTE 1 . The condition of CT 106 may also be affected by the state of any transmit buffer in the MT. 

NOTE 2. The condition of Status bit X towards the IWF may also be affected by the state of any receive buffer in 
the MT. 

NOTE 3: CT105 and CT133 are assigned to the same connector pin on both the standard 25 pin connector (ISO 
21 10) and the commonly used 9 pin connector (annex B). When this pin is used for CT133 then on the 
MT side of the interface CT 105 is treated as being always in the ON condition. SB towards the IWF will 
therefore also always be ON. 

Similarly, when this pin is being used for CT105 then on the MT side of the interface CT 133 is treated 
as being always in the ON condition. X towards the IWF will therefore also always be ON. 

As circuit 133 is used only in duplex operation and circuit 105 is used only in half duplex operation 
(which is not supported by GSM) there should be no conflict. 
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